There is an open discussion in #74 about which kinds of packages should belong in elm-community. The most recent example where this has practically played out is #98. Given this context, why do you want to move ordered-containers to elm-community?

Thanks for the links! They provide some more dimensions to the goals of this project that I hadn't thought about before.

To be honest, I think the idea came mostly to alleviate my maintainership burden. I don't believe that there is much potential for innovation with this package (and thus it probably doesn't fit the community-driven bullet point) and it does not appear to be widely used. I felt that it might fit with the dict-extra package, though.

My concern was mostly what originally happened to rnon's ordered-containers; that I had to fork it and publish a separate package to make it available for Elm 0.19. I hoped by moving it here, such a hand-over would be smoother. I am also willing to transfer the maintainership to someone, if someone wants it, which seems much simpler here.

However, I understand that there are reasons that speak against including the package here; the elm-community packages have a certain "official" feel and it won't magically assign a maintainer to every repo.

For some reason, I also didn't phrase the PR like I initially intended: I wasn't too sure about the inclusion myself and am open to hosting it on my handle, since I don't expect much maintainership anyway. So I'll let you guys have the final word on this! Either way is ok with me.

Have you decided already on what path you prefer? :)

Sorry, just to be clear I do not represent elm-community in any official capacity. Personally, I am against moving ordered-containers to elm-community because I do not think it is evident that it is "the one right solution" to the problem of ordered data structures. For instance, a package that I authored called assoc-list also solves the ordered dictionary problem and people have created derivatives of it to solve the ordered set problem. Curious to hear other people's opinions on this matter though.

Absolutely! After this discussion I also feel that the package does not fit the goal of elm-community providing a kind of "standard" for packages. It would only really fit the shared-maintainership part. And since the maintainership is probably not that bothersome, I am totally fine not integrating it here.

For the time being, I'll simply publish a new major version.

I'll still leave this open for a "official" decision, which might exemplify the issues in #74.